1. Field of the Invention
The present invention generally relates to the field of policy management, and more specifically, to policy based services management.
2. Description of the Relevant Art
Present enterprise information technology (“IT”) infrastructures are complex, multi-vendor environments. Each entity has its own behavioral characteristics and configuration properties. Configuring the entire IT environment to produce a desired aggregate behavior proves to be a difficult problem. Each hardware component, network entity and software application needs to be configured in a specialized manner.
With complex interactions between different components, there is no easy way to know the overall impact of each local configuration change. Typically, a trial and error approach is used. For example, a configuration property may be changed in the procurement application to double the number of clients that can simultaneously order supplies. However, soon after the change IT operators may realize that this configuration change can cause the overall performance of a critical order-management application to deteriorate because both applications route requests through the same web-server.
These kinds of problems have been explored in other domains, such as network management and storage management. From these, a very useful technique that has emerged is policy-based management. Policies allow an administrator to represent their desired behavior in a vendor-independent way. Policy-management products take these requirements and automatically map them to lower-level configuration for multiple heterogeneous systems. Policy managers analyze the requested policy and informing the administrator about the feasibility and impact of the desired policy.
In the example provided above, the IT administrator may request “I need more throughput for the procurement application.” The policy manager would know that the policy could be achieved by increasing the client-count property on the procurement application, but that such a change would cause deterioration of a critical order-management application. Armed with this analysis, the policy manager may offer a range of options to the administrator. For example, it may offer to force the change regardless of the impact, to allocate more machines to the web-server cluster, or to delay the change until more hardware can be acquired. That is, policy-oriented configuration abstracts the details of each application's configuration and aggregates them into goal-oriented choices that provide ease of use for IT administrators.
However, as enterprise applications have become increasingly distributed and draw upon shared resources, application management has not provided a policy-oriented approach that has had some success in these other domains. As an example, consider that there are two ways in which web-services impact policy-based management. The first way is standardization in application infrastructure makes application policy-management feasible. The second is application interactions increase and become wider in scope, making policy management vital.
With respect to the former example, a policy-based management works when there is a high degree of standardization on the components being managed. Such an approach has been successful in storage management, where there are well-defined interfaces for managing files and blocks. Likewise, applying such an approach in network management, routers and switches have well-defined tasks and there is a large body of shared knowledge on the implication of different configuration settings. By contrast software applications have tended to perform very proprietary tasks and are usually configured in proprietary ways, hence, having almost no policy management.
With respect to the latter example, many software applications are moving from a distributed systems model with centralized control to distributed systems with decentralized control. A difference in this shift is in the ownership of the interacting components. Previously, most, if not all, software that interacted with each other resided in a single trusted domain and could be managed centrally. Now, as interactions span organizational and company boundaries, it is impossible to administer, configure and update software systems centrally.
The problems caused by decentralized control are manifold. First, getting things to work is much more difficult because it is not possible to control both sides of the interaction. Well-defined interfaces are still important, but just as important, are all the operational details that are required to make the interaction work, and which are not specified in the interface definition. Details such as authentication method being used, number of concurrent connections accepted, session timeout, encryption parameters and the like are all important details necessary to make interactions work. This information has usually been transferred informally through documents, word-of-mouth or by encoding such parameters inside libraries. There is a lack of formal ways to represent and expose this policy-information so that consumers that want to talk to a service can query it and get policy-information about the service.
Second, as interactions cross-organizational boundaries, every interaction involves usage of resources owned by other parties. Attaining a certain quality of service for the applications becomes a shared responsibility and requires tools that allow administrators to expose configuration information to each other, as well as control each other's configuration in controlled ways. Third, decentralized control makes it harder to change configurations and upgrade systems. It is no longer possible to do synchronize systemic changes. Maintaining backward compatibility across all interacting parties becomes more difficult to achieve.
Hence, there is a need for infrastructure software that helps developers and administrators to administer software systems across organizational boundaries.